Virtualization system and operation management method

ABSTRACT

In a virtualization system that includes a hypervisor that performs OSID management for linking a plurality of OSs with resources, a guest OS that receives an initial value from the hypervisor and sets a OSID for each resource, and a OSID manager that sets a OSID for each resource, a new OSID created by OSID generator in OSID manager after a certain period of time has elapsed after setting the initial value is set to the guest OS and the IP (resource), and is requested to be updated to a new OSID set by the update controller in OSID manager. This enables simultaneous updating of OSID of the guest operating system and the resources, thus achieving high robustness.

CROSS-REFERENCE TO RELATED APPLICATIONS

The disclosure of Japanese Patent Application No. 2019-200651 filed onNov. 5, 2019 including the specification, drawings and abstract isincorporated herein by reference in its entirety.

BACKGROUND

The present invention relates to a virtualization system applied to anetwork-compatible vehicle-mounted system requiring high robustness, anautomatic driving system and the vehicle-mounted system such as an ADAS(Advanced Driver Assistance System).

The virtualization technology is a technology for organizing variousresources (CPU, memory, storage, Operating System (hereinafter, OS),etc.) of a computer system in a logical unit independent of a physicalconfiguration, so that a plurality of resources can be combined to beshown as a single resource, or a single resource can be divided intomultiple resources. In a system environment using such virtualizationtechnology, a virtual machine constructed by software on hardware isstarted, and the guest OS runs on it. As a method of constructing avirtual machine, there is a method of starting a dedicated softwarecalled a hypervisor on a computer and starting an OS on a virtualmachine constructed by a hypervisor. The hypervisor manages allocationinformation indicating the allocation of computer hardware resources(hereinafter referred to as resources) and creates a virtual physicalenvironment. The virtualization systems are implemented on System onChip (SoC).

To allocate and manage resources to guest OSs running on a virtualenvironment, each guest OS is given an OSID for identification. If theOSID is flexibly configurable in software without being anchored, thesoftware can be attacked and the OSID can be rewritten freely, and thereis a way to hide the OSID in hardware as a way to prevent the OSID fromsuch attacks.

FIG. 8 is a diagram illustrating a system configuration for concealingOSID from software attacks in a virtualization system. It consists of ahypervisor (8 c) running on a secure CPU, a guest OS1 (8 a) running on anon-secure CPU and a guest OS2 (8 d), a register (8 b) for storing OSIDof the guest OS1 (8 a), a register (8 e) for storing OSID of the guestOS2 (8 d), a gateway (8 f), an IP0 (8 i) and an IP1 (8 j) for accessingresources, a register (8 g, 8 h) which manages OSID of the guest OS forusing IP0 (8 i) and IP1 (8 j), and a resource (memory, etc.) (notshown).

Referring to FIG. 9, an operation flowchart for hiding OSID from asoftware-attack is described. The OSID (=A) allocated to the guest OS1(8 a) is generated by the hypervisor (8 c) based on the resource map orthe like immediately after the startup of the SoC which realizes thevirtualization system, and is held by the gateway (8 f) with superprivileges (S901). Next, the corresponding OSID is written to theregister (8 b) of CPU0 that runs the guest OS1 (8 a) (assuming that theregister cannot be directly referenced by another guest OS) with superprivileges. The guest OS1 (8 a) runs on non-secure CPUs (S902). Theguest OS1 (8 a) accesses resources through the gateway (8 f) usingassigned OSID (S903). The gateway (8 f) compares OSID requested foraccess with OSID stored in the register by the register (8 g, 8 h) thatstores OSID permitted for access to the resource, and permits access ifit matches. If there is a mismatch, accessing is not permitted (S904).If the guest OS1 (8 a) no longer uses the resource or wants to changethe resource to be accessed, it requests the hypervisor (8 c) to free orreallocate the resource (S905).

As described above, by storing OSID in the registers (8 g, 8 h) ofgateway (8 f), the register (8 b) of the guest OS1 (8 a) and theregister (8 e) of the guest OS2 (8 d) that cannot be referenced by otherguest OSs, the OSID is concealed as hardware and a high-securityenvironment in the virtualization system is realized.

SUMMARY

However, the prior art has the following problems. Once OSID has beenallocated, the generated OSID will continue to be used while the systemis running without modification. In such cases, for example, a maliciousguest OS may attempt to access unallocated resources and succeed inaccessing them by brute force attack while changing OSID sequentially.To solve this problem, it is possible to change OSID periodically.However, since OSID must be changed while the system is stopped, thesystem must be stopped and then restarted. In this method, however, itis virtually not possible to change OSID frequently in a short time.Furthermore, even if so as to secure a long change period, theintervention of software is required, it is feared that leads to adecrease in performance.

It is an object of the present invention to realize high security in avirtualization system while reducing the load of software processing ona function that restricts access to resources from a guest OS running ona non-secure CPU.

In a virtualization system having a hypervisor that performs OSIDmanagement for linking a plurality of OSs and resources, and an OSIDmanager that receives an initial value from the hypervisor and sets anOSID for linking in each of the guest OSs and resources, a new OSIDcreated by OSID manager is requested to be updated to the guest OS andresources after a certain period of time has elapsed after the initialvalue is set. This allows the guest OS and resource OSID to be updatedat the same time.

In a virtualization system according to an embodiment, by periodicallycreating an OSID by OSID manager and resetting OSID created in the guestOS and the resource, OSID that was previously operated at a fixed valuecan be updated while the system is running. Further, by simultaneouslyupdating by the update controller in OSID manager, it is possible toreliably update OSID while preventing mismatches generated by thedeviation of the update. This ensures that if a OSID is stolen in theevent of a brute force attack by a malicious OS, OSID is updatedimmediately, thus invalidating the stolen OSID and enabling a morerobust system.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a configuration diagram of a virtualization system accordingto the first embodiment.

FIG. 2 is a flowchart for updating OSID in the virtualization systemaccording to the first embodiment.

FIG. 3 is a configuration diagram of a virtualization system accordingto the second embodiment.

FIG. 4 is a flowchart of updating OSID in the virtualization systemaccording to the second embodiment.

FIG. 5 is a configuration diagram of a virtualization system accordingto a third embodiment.

FIG. 6 is a flowchart for updating OSID in the virtualization systemaccording to the third embodiment.

FIG. 7 is a configuration diagram of a OSID according to second modifiedexample.

FIG. 8 is a conventional virtualization system configuration diagram.

FIG. 9 is a flowchart for managing OSID in a conventional virtualizationsystem.

DETAILED DESCRIPTION First Embodiment

Hereinafter, the virtualization system according to the first embodimentwill be described in detail with reference to the drawings. In thespecification and the drawings, the same or corresponding elements aredenoted by the same reference numerals, and a repetitive descriptionthereof is omitted. In the drawings, for convenience of description, theconfiguration may be omitted or simplified. Also, at least some of theembodiments and each modification may be arbitrarily combined with eachother.

(Configuration of Virtualization System)

FIG. 1 is a block illustrating an overall configuration of avirtualization system according to the first embodiment. Thevirtualization system runs multiple guest OSs on a virtual environment.The virtualization system consists of a hypervisor (1 c) running on asecure CPU (central processing unit), a guest OS1 (1 a) and a guest OS2(1 d) running on a non-secure CPU, a register (1 b) that stores OSID ofthe guest OS1 (1 a), a register (1 e) for storing OSID of the guest OS2(1 d), an OSID manager (1 f), an IP0 (1 i), an IP1 (1 j), a register (1k) used by IP0 (1 i), a register (1 l) used by IP1 (1 j), resources suchas memory that are managed by IP0 (1 i) and/or IP1 (1 j) (not shown).The hypervisor (1 c) controls the operation of the guest OS1 (1 a) andthe guest OS2 (1 d) on the virtual environment, and manages OSID whichis the allocation information indicating the allocation of the resourcesof the virtualization system to the guest OS1 (1 a) and the guest OS2 (1d). The IP0 (1 i) and the IP1 (1 j) manage access to resources based onallocation information.

In the first embodiment, there is an OSID manager (if) as a control unitcorresponding to the gateway (8 f) in the prior art of FIG. 8. The OSIDmanager (1 f) has an update controller (1 g) for generating an OSID andan OSID generator (1 h). The OSID generator (1 h) generates OSIDallocated to the guest OS1 (1 a) and the guest OS2 (1 d). The updatecontroller (1 g) instructs the guest OS1 (1 a), the guest OS2 (1 d), theIP0 (1 i), and the IP1 (1 j) to use the update OSID as a new OSID.

(Update Flowchart of OSID)

Specifically, with reference to FIG. 2, OSID updating flow in presentembodiment is described. A guest OS1 (1 a) running on a non-secure CPU0submits a request to the hypervisor (1 c) to access IP0 (1 i) thatmanages the resource (S201). The hypervisor (1 c) generates OSID of theguest OS for accessing IP, and sets the generated OSID as initial value(S202). For instance, the hypervisor (1 c) assigns OSID (=A) to theguest OS1 (1 a). The OSID manager (1 f) sets initial OSID (=A) set bythe hypervisor (1 c) to IP0 (1 i), and OSID generator (1 h) generates anew OSID (=A′). The OSID manager (1 f) sets OSID assigned to IP0 (1 i)to CPU0 and makes CPU0 operational (S204).

The guest OS1 (1 a) uses OSID (=A) set in CPU0 to request access to theresources managed by IP0 (1 i) (S205). The IP0 (1 i) permits access tothe resource if the access request to the resource from the guest OS1 (1a) matches OSID set by OSID manager (if) (S206). If OSID does notmatched, access to the resource is not permitted. In this embodiment,OSID (=A) is set in the registers (1 b, 1 k) of the guest OS1 (1 a) andthe IP0 (1 i), so access is accepted. On the other hand, the OSIDmanager (if) transmits the generated new OSID (=A′) to IP0 (1 i) andCPU0 when the preset update timing (at a predetermined timing) hasarrived. Further, the OSID manager (1 f) instructs IP0 (1 i) and CPU0 toswitch to the transmitted OSID (S207).

Effect of First Embodiment

OSID can be changed frequently even while the system is running, and ifthe malicious guest OS forges OSID and becomes accessible tounauthorized resources, OSID is updated regularly and the successfullyaccessed OSID is immediately disabled. In other words, it is possible torealize high robustness, which is one of the important factors in theoperation of the guest OS in the virtualization system. Also, even ifOSID is updated frequently, the hypervisor implemented by the softwareis only involved in the initialization of OSID, and OSID manager managesthe updating of OSID so that the performance of the system is notdegraded.

Second Embodiment

FIG. 3 is a block illustrating an overall configuration of avirtualization system according to the second embodiment. It consists ofa hypervisor (3 c) running on a secure CPU, a guest OS1 (3 a) running ona non-secure CPU, a guest OS2 (3 d) running on a non-secure CPU, an OSIDmanager (3 f), an update controller (3 g) in the OSID manager (3 f), anOSID generator (3 b) in the guest OS1 (3 a), an OSID generator (3 e) inthe guest OS2 (3 e), IP1 (3 i), IP0 (3 h), an OSID generator (3 j) inthe IP0 (3 h), an OSID generator (3 k) in IP1 (3 i) and a resource suchas memory managed by OSID generator (3 j, 3 k) (not shown). The secondembodiment has a different configuration form first embodiment in thatwhere OSID generator is arranged.

In the second embodiment, as compared to the first embodiment, OSIDgenerator is disposed inside guest OS and IP. In addition, OSIDgenerator generates and uses OSID based on parameters such as seeds(variables) and calculate functions received from OSID, so that OSIDitself is not retained internally.

(Update Flowchart of OSID)

Specifically, refreshing OSID in present embodiment will be describedwith reference to FIG. 4. The guest OS1 (3 a) running on non-secure CPU0submits a seed update to a hypervisor (3 c) running on a secure CPU whena new resource is needed or OSID count is exhausted (S401). A seedincludes variables used to create OSID. The hypervisor (3 c) instructsan OSID manager (3 f) to send OSID generation parameters (seed,calculation function, number of generated, etc.) to CPU0 in which theguest OS1 (3 a) is running (S402). The OSID manager (3 f) sends OSIDgeneration parameters to CPU0 and IP0 (3 h) (S403). The guest OS1 (3 a)and IP0 (3 h) generate new OSID from OSID generation parameter and theprevious OSID by OSID generator (3 b, 3 j) which are arrangedinternally. In other words, the guest OS1 (3 a) and IP0 (3 h) calculatethe newly used OSID by a predetermined function (e.g., a function forcalculating OSID generation parameters) based on an instruction from theOSID manager (3 f), based on the parameters (e.g., seeds of OSIDgeneration parameters) and OSID used immediately before. The OSIDmanager (3 f) makes CPU0 operational (S405).

The guest OS1 (3 a) uses the generated OSID to request IP0 (3 h) toaccess the resource (S406). The IP0 (3 h) uses the generated OSID tomanage access to the resource (S407). The OSID for the access request iscompared with the generated OSID, and if they are the same, the accessrequest is accepted. The update controller (3 g) periodically (at apredetermined timing) instructs the guest OS1 (3 a) and IP0 (3 h) toupdate OSID. The OSID generator (3 b) and OSID generator (3 j)periodically generate OSID and update OSID that has been generated bythe instruction from the update controller (3 g). The old OSID isdeleted and disabled if OSID was updated (S408). It should be noted thatOSID should not be updated while CPU0 is locked by some kind of process.The guest OS1 (3 a) notifies the hypervisor (3 c) of completion when therequest of resource to IP0 (3 h) is completed (S409).

Effect of Second Embodiment

In the second embodiment, since OSID to be retained is generated by OSIDgenerator each time both the guest OS and the IP (resource), there is noneed to retain OSID itself, and OSID can be completely concealed.Moreover, since the data held by the guest OS and the IP (resource) areonly parameters for OSID generation, even if the parameters are stolen,it is impossible to generate an OSID unless the algorithm for generatingOSID is clarified, and high-robustness can be realized.

Third Embodiment

FIG. 5 is a block showing the overall configuration of thevirtualization system according to the third embodiment. A hypervisor (5c) running on a secure CPU, a guest OS1 (5 a) running on a non-secureCPU, a guest OS2 (5 d) running on a non-secure CPU, an OSID generator (5b) in the guest OS1 (5 a), an OSID generator (5 e) in the guest OS2 (5d), an OSID manager (5 f), an IP0 (5 g), an IP1 (5 i), an OSID generator(5 h) in the IP0 (5 g), an OSID generator (5 j) in the IP1 (5 i), and aresource managed by a IP0 (5 b) such as memory (not shown). The thirdembodiment has a different configuration from the first embodiment inthat where OSID generator is arranged. Further, the third embodiment hasa different configuration from the second embodiment in that there is noupdate controller.

In the third embodiment, the updating instruction by OSID manager isunnecessary. As in the second embodiment, OSID generator is locatedinside the guest OS and the resource, and generates OSID according tothe parameters from OSID manager. The guest OS accesses the resource byupdating OSID at predetermined intervals (at a predetermined timing)such as every access or every 10 accesses, for example. OSID is updatedin the same way when the number of accesses is counted and thepredetermined update timing is reached. The refresh interval is presetby OSID manager.

(Update Flowchart of OSID)

Specifically, with reference to FIG. 6, the flowchart of updating OSIDin the present embodiment will be described. The guest OS1 (5 a) runningon non-secure CPU0 submits a request of seed update to a hypervisor (5c) running on a secure CPU when a new resource is needed or OSID countis exhausted (S601). A seed includes variables used to create OSID. Thehypervisor (5 c) instructs OSID manager (5 f) to send OSID generationparameters (seed, calculation function, number of generated, etc.) toCPU0 in which the guest OS1 (5 a) is running (S602). The OSID manager (5f) sends OSID generation parameters to CPU0 and IP0 (5 g) (S603). Theguest OS1 (5 a) and IP0 (5 g) generate new OSID from OSID parameter andthe previous OSID by OSID generator (5 f) and the OSID generator (5 h)which are arranged internally. In other words, the guest OS1 (5 a) andIP0 (5 g) calculate the newly used OSID by a predetermined function(e.g., a function for calculating OSID generation parameters) based onthe parameters (e.g., seeds of OSID generation parameters) and OSID usedimmediately before. The OSID generation parameters become enable CPU0(S605).

The guest OS1 (5 a) uses the generated OSID to manage access toresources (S606). The IP0 (5 g) uses the generated OSID to manage accessto the resource (S607). The OSID of the access request is compared withthe generated OSID, and if they are the same, the access request isaccepted. In OSID generator (5 b) and OSID generator (5 h) arrangedinside the guest OS1 (5 a) and IP0 (5 g), OSID is generated at apredetermined timing, and the stale OSID is erased and disabled (S608).As a predetermined timing, when the number of times the guest OS1 (5 a)requested to access IP0 (5 g) reaches a predetermined value, whereaswhen the number of access requests from the guest OS1 (5 a) reaches apredetermined number of times, OISD may be updated. OSID should not beupdated while the CPUs are locked. The guest OS1 (5 a) notifies thehypervisor (5 c) of completion when resource-requesting to IP0 (5 g) iscompleted (S609).

Effect of Third Embodiment

In the third embodiment, the access from the guest OS to the IP(resource) is an order-guaranteed access, and by determining the updatetiming based on this access, the access can be made accessible withoutinconsistent OSID even if there is no update instruction from OSIDmanager. Further, since OSID manager does not need to perform updatingcontrol for the respective guest OSs and IPs (resources), frequentperiodic updating of OSID can be performed without complicated controleven when the number of control targets increases.

First Modified Example

For example, there is a way to simplify the function of OSID generatingpart. In the second and third embodiments, the OSID generators insidethe guest OS and IP generate OSID, but instead of providing OSIDgenerator, OSID storage table can be retained. The OSID manager storesOSID in OSID storage table and sequentially updates OSID in the table ata predetermined update timing. For example, guest OS1 (3 a, 5 a) and IP0(3 h, 5 g) are generated from OSID storage table as the allocationinformation table based on the parameters and OSID used immediatelybefore based on the instruction from OSID manager (3 f, 5 f). If OSIDreaches the end of the table, it should return to the beginning at thenext refresh timing. In this method, a simpler configuration and morerobust virtualization system can be constructed than with an OSIDgenerator.

Second Modified Example

When OSID generator in above embodiments individually generates an OSID,there is a possibility that the generated OSID overlaps. To solve thisproblem, as shown in FIG. 7, OSID is configured by the OS identificationpart (7 a) and OSID part (7 b). The OS identification part (7 a) storesa predetermined number for each guest OS. In the configuration exampleof FIG. 7, it is possible to support up to four OSs. When OSID is 16bits, the bit position of the OS identification part (7 a) and OSID ofthe OS allocated to each OS correspond to the OS identification part (7a), such as bit 0 being the guest OS0 and bit 1 being the guest OS1. Bysetting bit 0 of the OS identification part (7 a) to “1”, it isidentified as an OSID for guest OS0. When access is permitted frommultiple OSs, the corresponding bit position is set to “1” in the sameway. For example, when only guest OS0 and guest OS3 are allowed, the OSidentification part (7 a) becomes “1001”

What is claimed is:
 1. A virtualization system that runs multiple guestoperating systems in a virtual environment, comprising: a hypervisorthat controls operations of the plurality of guest operating systems ona virtual environment and manages allocation information indicatingallocation of hardware resources of the virtualization system to theguest operating system, an IP that manages access to the hardwareresource based on the allocation information and a control unit forupdating the allocation information and transmitting the allocationinformation updated to the guest OS and the IP, wherein the guest OSrequests the IP to access the hardware resource based on the allocationinformation allocated to itself, wherein the IP determines whether ornot to permit a request for access from the guest OS based on theallocation information allocated to itself.
 2. The virtualization systemaccording to claim 1, wherein the control unit updates the allocationinformation at a predetermined timing, transmits the allocationinformation to the guest OS and the IP, and instructs switching to theupdated allocation information.
 3. A virtualization system that runsmultiple guest operating systems in a virtual environment, comprising: ahypervisor that controls operations of the plurality of guest operatingsystems on a virtual environment and manages parameters for generatingallocation information indicating allocation of hardware resources ofthe virtualization system to the guest operating system, an IP thatmanages access to the hardware resource based on the allocationinformation, and a control unit for transmitting the update instructionof the allocation information to the guest OS and the IP, wherein thehypervisor transmits the parameters to the guest OS and the IP, whereinthe guest OS generates the allocation information by the parameter, andrequests the IP to access the hardware resource based on the generatedallocation information, wherein the IP generates the allocationinformation based on the parameter, and determines whether or not topermit a request for access from the guest OS based on the generatedallocation information.
 4. The virtualization system according to claim3, wherein the control unit transmits an update instruction of theallocation information to the guest OS and the IP at a predeterminedtiming.
 5. The virtualization system according to claim 4, wherein theguest OS and the IP calculate the newly used allocation information by apredetermined function based on the parameter and the allocationinformation that has been used immediately before based on aninstruction from the control unit.
 6. The virtualization systemaccording to claim 4, wherein the guest OS and the IP are generated froman allocation information table based on the parameter and theallocation information used immediately before based on an instructionfrom the control unit.
 7. A virtualization system that runs multipleguest operating systems in a virtual environment, comprising: ahypervisor that controls operations of the plurality of guest operatingsystems on a virtual environment and manages parameters for generatingallocation information indicating allocation of hardware resources ofthe virtualization system to the guest operating system, an IP thatmanages access to the hardware resource based on the allocationinformation, wherein the hypervisor transmits the parameters to theguest OS and the IP, wherein the guest OS generates the allocationinformation by the parameter at a predetermined timing, and requests theIP to access the hardware resource based on the generated allocationinformation, wherein the IP generates the allocation information by theparameter at a predetermined timing and determines whether or not topermit a request for access from the guest OS based on the generatedallocation information.
 8. The virtualization system according to claim7, wherein the guest OS and the IP calculate, based on an instructionfrom the control unit, the newly used allocation information by apredetermined function based on the parameter and the allocationinformation that has been used immediately before.
 9. The virtualizationsystem according to claim 7, wherein the guest OS and the IP aregenerated from an allocation information table based on the parameterand the allocation information used immediately before based on aninstruction from a control unit.
 10. The virtualization system accordingto claim 7, wherein the predetermined timing is a timing at which theguest OS requests a predetermined number of hardware resources to theIP.
 11. A method of managing operation in a virtualization system thatruns multiple guest operating systems in a virtual environment,includes: a step for controlling by a hypervisor operations of theplurality of guest operating systems on a virtual environment andmanages allocation information indicating allocation of hardwareresources of the virtualization system to the guest operating system, astep for managing access by an IP to the hardware resource based on theallocation information, a step for updating the allocation informationby the control unit, and transmitting the allocation information updatedto the guest OS and the IP, a step for requesting the IP by a guest OSto access the hardware resource based on the allocation informationallocated to itself, a step for determining whether or not the IPpermits a request for access from the guest OS based on the allocationinformation allocated to itself.